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METHOD AND APPARATUS FOR PRIVATE 
MESSAGING AMONG USERS SUPPORTED 
BY INDEPENDENT AND INTEROPERATING 

COURIERS 

Related Applications 

[0001] This application claims the benefit of U.S. Provisional 

Patent application 60/477,736 filed on June 11, 2003 and 
is a continuation-in-part of U.S. Serial No. 10/701,355 
filed on November 4, 2003, which claims the benefit of 
U.S. provisional applications 60/423,705 filed on Novem- 
ber 4, 2002, 60/436,227 filed on December 23, 2002 and 
60/466,910 filed on May 1, 2003 all of the disclosures of 

which are incorporated herein by reference. 
Technical Field 

[0002] This invention pertains in general to electronic messaging 
such as electronic mail ('email') and similar communica- 
tion, and in particular to providing message privacy ser- 
vices. 



Background of the Invention 



[0003] united States Provisional Patent Application 60/466,910 
entitled SYSTEM, METHOD, AND APPARATUS FOR SIMPLI- 
FIED PRIVATE MESSAGING by the present inventors, 
(hereinafter referred to as 'the foundation disclosure') de- 
scribes a distributed system of client and server software 
capabilities that cooperate to provide messaging privacy 
services. That system, which is being marketed under the 
name ArmorPost, makes two significant assumptions 
about its operating environment. 

[0004] First, the Trusted Courier is a single network element 
owned by a single entity. While this serves the needs of 
that single entity, and provides effective service for all 
users, it is not possible to establish competing yet inter- 
operating message privacy services using the single- 
Courier design described in the foundation disclosure. 
Further, it may be difficult for security-sensitive organiza- 
tions to deploy a Trusted Courier as described in the 
foundation disclosure inside their enterprise networks and 
thereby exert a measure of control over their private mes- 
saging traffic. 

[0005] what is needed, then, is an extension to the system de- 
scribed in the foundation disclosure which allows for mul- 



tiple Trusted Couriers to operate independently of one 
another with respect to their own users, yet interoperate 
with one another to transport Private Messages and re- 
lated services among their disparate user communities. 

[0006] Second, the Trusted Courier represents a nexus through 
which both Private Messages and their corresponding Ac- 
cess Restrictions Messages flow. The fact that these mes- 
sages are sent separately in time provides substantial se- 
curity. However, an even greater degree of assurance 
against abuse of the Trusted Courier's unique position in 
the network can be achieved by routing those two mes- 
sages through completely separate elements. 

[0007] what is needed, then, is an extension to the system de- 
scribed in the foundation disclosure which allows for any 
Trusted Courier to be distributed across two network 
servers, which may be further distributed even to two 
physical sites separated by a significant distance, such 
that encrypted message content flows through one server 
while corresponding content key material flows through 
the other. 

[0008] it is thus a principal aim of the present invention to create 
architectures and protocols for distributing and replicat- 
ing the Trusted Courier, thereby enhancing its applicabil- 



ity and trustworthiness. 
Summary of the Invention 

[0009] The present invention provides a private messaging sys- 
tem using trusted couriers to relay private messages as 
well as key material used to protect the private messages 
that is enhanced by the deployment of multiple indepen- 
dent yet interoperating Trusted Couriers. Preferably, the 
independent trusted couriers may be operated by inde- 
pendent organizations, some of which may compete with 
one another for users and others of which may support 
closed user communities. The present invention contem- 
plates that any of these independent organizations may 
choose to operate multiple trusted couriers itself, whether 
for the purpose of aligning traffic distribution with enter- 
prise network architecture, for the purpose of providing 
greater capacity than is achievable in a single node, or for 
any other reason. 

[0010] it is also contemplated that any single trusted courier may 
be deployed in such a way as to separate the handling of 
private message content and access restrictions messages 
that contain key material. While the basic methods for 
such handling are described in Provisional Application 
60/466,910, the present invention provides enhanced 



methods that ensure the two messages which correspond 
with one another are not handled in the same network el- 
ement. In other words, key material used to protect a par- 
ticular private message is handled by a set of network ele- 
ments that are at least partially and preferably wholly in- 
dependent of the network elements used to convey the 
private message. 
[0011] The above and other advantages of the present invention 
are carried out in one form by a system of cooperating el- 
ements, each of which applies cryptographic and other 
procedural means as specified below to effect the desired 
distribution and replication of trusted couriers, while con- 
tinuing to ensure the privacy of each message as it is con- 
veyed from its sender to its recipients across multiple 
couriers and courier partitions, as well as continuing to 
permit the establishment and enforcement of access re- 
strictions by that sender. 
Description of Drawings 

[0012] Th e invention will be better understood from a reading of 
the following detailed description in conjunction with the 
drawing figures, in which like reference designators are 
used to identify like elements and in which: 

[0013] FIG. 1 illustrates a high-level block diagram of the multi- 



Courier Private Messaging system of the present inven- 
tion; 

[0014] FIG. 2 illustrates a block diagram exemplifying the topol- 
ogy of the Courier Network of the present invention; 

[0015] FIG. 3 illustrates a combination signaling sequence chart 
and flow chart for the Registration process in accordance 
with the present invention; 

[0016] FIG. 4 illustrates a combination signaling sequence chart 
and flow chart for the Key Replacement process in accor- 
dance with the present invention; 

[0017] FIG. 5 illustrates a combination signaling sequence chart 
and flow chart for the Registration Transfer process in ac- 
cordance with the present invention; 

[0018] FIG. 6 illustrates a combination signaling sequence chart 
and flow chart for a Message Transfer involving a single 
Trusted Courier with separate foreground and background 
elements in accordance with the present invention; 

[0019] FIG. 7 illustrates a combination signaling sequence chart 
and flow chart for a Message Transfer involving two 
Trusted Couriers, which have been previously introduced 
to one another, in accordance with the present invention; 

[0020] FIG. 8 illustrates a combination signaling sequence chart 
and flow chart for a Message Transfer involving two 



Trusted Couriers, which have not been previously intro- 
duced to one another, as well as the Deferral procedure 
which intervenes to ensure end-to-end flow and the In- 
troduction procedure which follows to prevent future De- 
ferrals between these two Trusted Courier pairs, in accor- 
dance with the present invention; and 
[0021] FIG. 9 illustrates a combination signaling sequence chart 
and flow chart for a Message Transfer involving two 
Trusted Couriers, the first of which Invites an Agent that is 
Registered in the second, as well as the Invitation Reject 
procedure which intervenes to ensure correct end-to-end 

handling, in accordance with the present invention. 
Detailed Description of the Preferred Embodiments 

[0022] | n FIG. 1 Multi-Courier Private Messaging System 100 rep- 
resents the system in accordance with the present inven- 
tion. Four major elements make up this system. First, 
End-to-End Messaging Infrastructure 101 represents the 
messaging backbone to which the Private Messaging ca- 
pability of the foundation disclosure, as enhanced by the 
present invention, is added. This Infrastructure can be any 
messaging system that allows users and/or software enti- 
ties to exchange messages with one another. It is prefer- 
ably the Internet-standard email service, but may also be 



implemented as an instant messaging service, a wireless 
short message service (SMS), any other messaging service, 
or any combination of these. Second, Packet Network 102 
forms the foundation for all communication among ele- 
ments, including End-to-End Messaging Infrastructure 
101 and the messages exchanged thereon, but also sup- 
porting other non-messaging interactions such as web 
browsing. This element is preferably an Internet-based 
network, and may be the Internet itself, another network 
like it, or a composite of networks using multiple inter- 
networking technologies. 
[0023] Third, connected to End-to-End Messaging Infrastructure 
101 and Packet Network 102 are one or more Agents 110, 
which are computer software applications and devices 
which enable the Private Messaging capability for an end 
user. Each Agent 110 is a composite of some existing 
Messaging Client 112, an Information Security component 
111, an interface 113 to the Messaging Infrastructure 
101, and an interface 114 to the Packet Network 102. 
Agent 110 and its components are described in detail in 
the foundation disclosure, and are used here exactly as 
they are there. 

[0024] Fourth, also connected to Messaging Infrastructure 101 



and Packet Network 102 are a plurality of Trusted Couri- 
ers 103. These fill the same functional role as the Trusted 
Courier described in the foundation disclosure. However, 
where that system included only a single Trusted Courier, 
here any number may appear. This replication of the func- 
tion satisfies the multiple ownership and traffic dispersion 
goals cited above. 

[0025] | n the present invention each Trusted Courier 103 com- 
prises a Background and a Foreground element, such that 
Background and Foreground signaling as defined in the 
foundation disclosure are handled in completely separate 
Courier elements. This enhances the security of the sys- 
tem because with foreground and background signaling 
handled separately, the content of any single Private or 
Restricted Message cannot be decrypted by any Trusted 
Courier. This satisfies the distribution goal cited above. 

[0026] Each Trusted Courier 103 comprises two elements. 

Trusted Courier Foreground Element 120 is substantially 
identical in every way to Trusted Courier 120 from the 
foundation disclosure. Trusted Courier Background Ele- 
ment 130 is based on Trusted Courier 120 from the foun- 
dation disclosure, and its Information Security module 
131 is substantially identical to Information Security mod- 



ule 121 from the foundation disclosure. Trusted Courier 
Background Element 130 differs from the previous 
Trusted Courier 120 in that it lacks an Account Manage- 
ment module; no such module is necessary in Trusted 
Courier background element 130 because the Account 
Management module 122 in its corresponding Trusted 
Courier foreground element 120 serves for the entire 
Trusted Courier 103. It also differs in that it has no Inter- 
face 123 to Messaging Infrastructure 101; because 
Trusted Courier background element 130 handles only 
background element signaling, it interacts directly with 
Agents 110 and other Trusted Courier background ele- 
ments 130 only via its Interface 124 and Packet Network 
102. 

[0027] Note that there is no direct interface within Trusted 

Courier 103 between Courier foreground element 120 and 
Courier background element 130. This attribute prevents 
abuse of Trusted Courier 103's sensitive position in the 
message flow network. The few interactions that are re- 
quired between Courier foreground element 120 and 
Courier background element 130, which will become clear 
as the methods of the present invention are explained be- 
low, take place through Packet Network 102 on their re- 



spective Interfaces 124. This interface choice also pro- 
vides a great deal of architectural flexibility in the deploy- 
ment of Trusted Couriers 103. Courier foreground ele- 
ment 120 and Courier background element 130 may be 
situated as close to or as far from one another as their 
operator deems appropriate. For example, they may be 
deployed in the same room on the same Internet access 
interface, in different cities, or using any topology in be- 
tween. It is also conceivable that they may be imple- 
mented as separate processes in the same computer, al- 
though this is not expected to be common or advisable 
due to security concerns. The foundation disclosure de- 
tails the structure and functionality of Agents 110 and 
Trusted Courier Elements 120/130, which description is 
incorporated herein by reference. 
[0028] FIG. 2 shows a schematic summary of the possible topolo- 
gies in which the multiple Trusted Couriers 103 of Multi- 
Courier Private Messaging System 100 may be arranged 
relative to one another. This figure depicts four distinct 
organizational roles a Trusted Courier 103 might play in 
the network, along with two distinct inter-Courier rela- 
tionships. The organizational roles represent different 
sets of constraints on certain significant behaviors, which 



make each particular role suitable for certain types of or- 
ganization. The relationships pertain to how these Couri- 
ers interact with one another to form networks. Note that 
these relationships represent meaningful interactions, not 
direct communication links. All communication takes 
place via Packet Network 102. Also note that Agents 110 
are not shown in this diagram, but are instead implied. 
Each User and Agent is registered with and served by a 
single Courier. Thus each Trusted Courier 103 forms an 
island of service, and with respect to the Private Messag- 
ing service acts as a gateway for its registered Agents/ 
Users. The relationships among Trusted Couriers 103 rep- 
resented in FIG. 2 insulates those Agents 110 from one 
another, particularly with respect to encryption/au- 
thentication certificates. 
[0029] As was stated in the foundation disclosure, simplification 
of the User's encryption/authentication experience is a 
significant benefit of the Private Messaging system, and 
this is accomplished by having the Trusted Courier act as 
a proxy for all other correspondents. This leads directly to 
the purpose of Relationships 201 (indicated by bold lines 
in Fig. 2), which are between one Trusted Courier 103 and 
another Trusted Courier 103 which certifies the authentic- 



ity of the first by signing its encryption/authentication 
certificate. In order for every Agent 110 served by a 
Courier 103 to trust messages from every Agent 110 
served by every other Courier 103, there exists a network 
of certificate authenticity in which every Trusted Courier 
103 participates. This network is depicted in FIG. 2 as a 
pure hierarchy. Note that each Trusted Courier 103 has 
exactly one Relationship 201 superior, and may have 
many Relationship 201 inferiors. No peer Relationships 
201 may exist, as there is no meaning within a certifica- 
tion hierarchy for such peering. Thus the Couriers 103, 
each of which is a Certificate Authority for its Agents 110 
and any other Couriers 103 which subtend it, form a con- 
ventional Certificate Authority tree via their Relationships 
201 with one another. At the top of this tree is Root 
Courier 200, which acts as the root Certificate Authority 
for the entire network. Conventional Public-Key Infras- 
tructure technologies and techniques, well known to those 
skilled in the art, are used to form this tree. 
[0030] The Root Courier 200 role is filled by exactly one Trusted 
Courier 103 in the network. In the preferred embodiment, 
this is the Trusted Courier 103 operated by the authors of 
the present invention, although the business environment 



will dictate whether this continues to be the case. 

[0031] Public Courier 210 and Private Courier 220 represent 

Couriers 103 that are operated by different classes of or- 
ganization, and which have different constraints on their 
service domain. A Public Courier is permitted to serve any 
User without constraints, while a Private Courier is con- 
strained to serve only those Users whose addresses fall 
within the same network namespace as the Private 
Courier. For example, a Private Courier in a particular In- 
ternet Domain Name would only serve Users whose email 
addresses are also in that same Internet Domain Name. 
Typically, a major ISP or carrier would operate a Public 
Courier, while an Enterprise or small ISP would operate a 
Private Courier. For example, Public Courier 210 might be 
a major ISP serving numerous Users in multiple domains, 
while Private Couriers 211 and 212, which subtend it in 
the CA hierarchy, might be particular Enterprises that are 
customers of that ISP but operate their own Couriers for 
security reasons. As another example, Private Courier 220 
might be the first Courier placed in service by a large En- 
terprise, which later installed Private Couriers 221 and 
222 to diversify their traffic. 

[0032] Behaviorally, the primary difference between Public and 



Private Couriers is how they handle recipient addresses 
that are not registered. A Public Courier will invite these 
Users according to the procedures in the foundation dis- 
closure. Because there are no domain constraints on a 
Public Courier, this practice carries a risk of inviting a User 
who is already Registered in some other Courier, Public or 
Private. FIG. 9 depicts this situation, which will be de- 
scribed below. On the other hand, a Private Courier will 
Defer the message to its Relationship 201 superior be- 
cause its domain of service is constrained. The superior 
Courier, and its superiors up to Root Courier 200 if nec- 
essary, will resolve the unknown recipient address. This 
situation is depicted in FIG. 8, which will be described be- 
low. Note that Root Courier 200 is also a Public Courier. 
[0033] while the Relationship 201 hierarchy is appropriate for 

certificate authentication, it is not optimal for traffic flow. 
Relationships 202 (indicated by non-bold lines in Fig. 2) 
represent the opportunity for flow of Private/Restricted 
Messages, Access Restrictions Messages, and other traffic 
between Couriers 103 so related on behalf of their Agents 
110. For such traffic to flow, the Couriers 103 involved 
have previously exchanged encryption/authentication cer- 
tificates with one another so that information privacy and 



authenticity are ensured. Note that these certificates are 
governed by the certificate authenticity hierarchy formed 
of Relationships 201, so every participating Trusted 
Courier 103 may be assured of the others by validating 
the certificates up to the Root Courier 200. This exchange 
process is called Introduction, and the mechanics of it are 
depicted in FIG. 8, which will be described below. Here it 
is sufficient to note that any Courier 103 may be intro- 
duced to any other Courier 103, thus forming a traffic 
mesh according to the demand of the Agents 110 in- 
volved. Thus an optimal network is formed dynamically. 
Note that a Relationship 202 is automatically formed in 
parallel with every Relationship 201 as a corollary to the 
certificate authentication process. Additional Relation- 
ships 202 form as demanded by the traffic flow, and may 
appear anywhere. 
[0034] Certain regulatory environments may exist which con- 
strain the any-to-any formation of Relationships 202. In 
such situations a Gateway Courier 230 role is conceived 
which focuses all Introduction activity, and therefore all 
inter-Courier traffic, on itself for a particular segment of 
the network for which it is responsible. Note in FIG. 2 how 
Private Couriers 231 and 232 have no Relationships 202 



which bypass Gateway Courier 230. Formation of this 
topology is a special case of the procedures described be- 
low, and requires no additional procedures. Gateway 
Courier 230 may also be either a Private Courier or a Pub- 
lic Courier, as the relevant behavioral characteristics for 
determining Public vs. Private or Gateway vs. non-Gateway 
are orthogonal to one another. 

[0035] | n Figures 3 through 9 we find the major methods which 
operate in the Multi-Courier Private Messaging System 
100 that are different from or in addition to the proce- 
dures in the foundation disclosure. As Invitation remains 
unchanged from the foundation disclosure, we begin with 
Registration in FIG. 3. The change appears at the end of 
the process, but the description here will recap in abbre- 
viated form the steps that have not changed as well. 

[0036] Registration begins with step 301, in which the registering 
user receives an Invitation as described in the context of 
the foundation disclosure's FIG. 4. Imbedded in the Invita- 
tion message is a referral link, and in step 302 the user 
follows this link with a web browser and fills out the re- 
sulting form. Step 303 condenses the retrieval and sub- 
mittal of the form, which appear as steps 503-506 in the 
foundation disclosure's FIG. 5. 



[0037] Upon receipt of the completed form in step 303, Trusted 
Courier foreground element 120 will at step 304 create 
the user's account, and at step 305 construct an Agent In- 
staller for the user. The Agent Installer is a software appli- 
cation that will install an Agent 110 in the user's computer 
or device. The Agent Installer package is downloaded to 
the user's computer or device in step 306, through the 
same secure path used by the registration form in step 
303. The Agent Installer is executed in the User's com- 
puter or device at step 307. The foregoing steps 304-307 
correspond exactly to steps 507-510 in the foundation 
disclosure's FIG. 5. 

[0038] During installation, the installer establishes that it has 

landed in the right place, so its first action at step 308 will 
be to validate its configuration as described in step 511 of 
the foundation disclosure's FIG. 5, and prompt the User 
for a local password as described in step 512 of the foun- 
dation disclosure's FIG. 5. The User will create and enter 
the requested local password at step 309, and the Agent 
Installer will store it and create the necessary encryption 
keys at step 310; these steps correspond exactly to steps 
513-515 in the foundation disclosure's FIG. 5. 

[0039] Next, the Agent Installer and Trusted Courier foreground 



element 120 will in steps 311-313 exchange keys with 
one another and store the results of the exchange, in ex- 
actly the manner as described in detail for steps 516-520 
of the foundation disclosure's FIG. 5. The foundation pro- 
cedure concludes with an Agent Alive Indication message 
being sent by the Agent Installer to Trusted Courier fore- 
ground element 120 in steps 314-315, corresponding ex- 
actly with final steps 521-522 of the foundation disclo- 
sure's FIG. 5. 

[0040] At this point, however, the present invention continues so 
as to ensure that both Trusted Courier foreground Ele- 
ment 120 and Trusted Courier background element 130 
are operating with the same data regarding the Register- 
ing User and Agent 110. Step 316 shows Trusted Courier 
foreground element 120 sending a Distribute Account 
message to Trusted Courier background element 130. 
This message carries the User's and Agent's addresses, 
along with encryption keys for both Courier and Agent. 
The Registration procedure concludes at step 317 with 
Trusted Courier background element 130 activating its 
view of the User's account. 

[0041] N 0te t hat both foreground element and background ele- 
ments will operate with the same keys, including the 



Courier-end private key. While this is perhaps unconven- 
tional compared with prior-art public-key cryptography, it 
permits Agent 110 to be somewhat simpler than would be 
the case if Trusted Courier foreground element 120 and 
Trusted Courier background element 130 used separate 
keys to communicate with Agent 110. In particular it 
avoids the necessity to execute the Key Replacement pro- 
cedure with both halves of the Trusted Courier 103. 
[0042] FIG. 4 depicts an exemplary process of replacing crypto- 
graphic keys. Functionally, steps 401-409 correspond ex- 
actly to steps 601-609 of the foundation disclosure's FIG. 
6, and so are not detailed further. However, due to the 
separation of foreground element and background ele- 
ment steps 402 and 407 are extended as described here, 
and additional steps 410-412 are required to synchronize 
the two elements in the Courier. Trusted Courier fore- 
ground element 120 drives the Key Replacement process 
from the perspective of Trusted Courier 103, but Trusted 
Courier background element 130 participates in two ways. 
First, because Agent 110 can only receive background 
messages from Trusted Courier background element 130, 
the Notice to Rekey and Exchange Keys messages are re- 
layed through it. Therefore steps 402 and 407, respec- 



tively, depict these messages going not directly to Agent 
110 but to Trusted Courier background element 130, 
which performs a relay function in steps 402a and 407a. 
The messages then go to Agent 110 at steps 402b and 
407b, respectively. Note that the Exchange Keys message 
in step 404 and the Rekeying Complete message in step 
409, though logically background messages, can never- 
theless be sent straight into Trusted Courier foreground 
element 120 by Agent 110 due to the nature of the un- 
derlying messaging protocols. Second, because Trusted 
Courier background element 130 does not participate 
logically in the Key Replacement that concludes at step 
409, it is informed of the result by Trusted Courier fore- 
ground element 120. The latter does so at step 410, con- 
veying to the former in step 411a background element 
Key Replacement message that carries the new keys for 
both Trusted Courier 103 and Agent 110. Trusted Courier 
background element 130 records these new keys in its 
database at step 412. 
[0043] The observant reader will note that in neither the Regis- 
tration process of FIG. 3 nor the Key Replacement process 
of FIG. 4 does Trusted Courier background element 130 
respond to Trusted Courier foreground element 120 after 



receiving the database updates. The principle being fol- 
lowed here is that Courier background element 130 is 
subservient to Courier foreground element 120 and can- 
not have any opportunity to reject the update. In addition, 
the absence of any routine signaling from Courier back- 
ground element 130 to Courier foreground element 120 
contributes further to the prevention of any potential 
abuse whereby Courier background element 130 might 
relay an Access Restrictions Message to Courier fore- 
ground element 120 and subvert the separation. 
[0044] with multiple Trusted Couriers 103 in the network, it is 
inevitable that Users will migrate among them in certain 
situations. As the network of Couriers owned by a single 
operator grows, for example, that operator will want to 
distribute the Users among the various Couriers 103 for 
appropriate load balancing and optimal traffic flow. Public 
Couriers as well will tend to compete with one another for 
Users, so some churn is to be expected in the network. 
Both situations require a controlled mechanism for mov- 
ing a User's Registration from one Courier 103 to another. 
The procedure used to do this will optimally involve the 
operators of both Couriers 103 (even when they are the 
same entity), so that no question will arise as to whether a 



particular transfer was appropriate. It should never be 
possible for the operator of a Trusted Courier 103 to 
'slam' a User's Registration unilaterally. Further, while a 
User should be able to trigger a transfer, the process itself 
should be handled automatically without additional User 
intervention. 

[0045] FIG. 5 depicts a Registration Transfer procedure that sat- 
isfies these requirements. The process begins with the 
operator(s) of the two involved Trusted Couriers 103 
agreeing at step 501 to perform the transfer of a particu- 
lar User. This is a business-process step that may or may 
not involve automation but definitely involves human de- 
cisions. As such the details of this part of the procedure 
will vary among different operators and are not further 
specified here. In the case of a User-initiated transfer, this 
decision step also offers the operator of the old Courier 
103 an opportunity to attempt various marketing actions 
that might retain the customer. 

[0046] Once the transfer is agreed, the respective operators will 
set the system to perform it. In step 502, the operator of 
the Courier 103 that will gain the User, termed here the 
'new' one, will through an administrative action record the 
transferring User's messaging address such that 'new' 



Courier foreground element 120 will accept the transfer 
and execute the automated steps involved. At the same 
time, in step 503 the operator of the Courier 103 that will 
lose the User, termed here the 'old' one, will through an 
administrative action initiate the automated portion of the 
procedure. Note that this implies the 'old' Courier 103 and 
its operator cooperate in the transfer, in fact to the point 
of actively relinquishing the User. Between this and the 
continued use of cryptographic authentication throughout 
the process, slamming is quite impossible. 
[0047] The automatic portion of the Registration Transfer proce- 
dure commences then at step 504, wherein the 'old 1 
Courier foreground element 120 transmits the User's sub- 
scription data and Agent key to 'new' Courier foreground 
element 120 in a Transfer Subscription message. Note 
that, as with Registration and Key Replacement, Courier 
foreground element 120 drives the process, only inform- 
ing Courier background element 130 after certain key 
steps. Note also that this message is preferably encrypted 
to protect its sensitive content, as are all others in the 
system of the present invention and the foundation dis- 
closure. 

[0048] upon arrival of the Transfer Subscription message, 'new' 



Courier foreground element 120 at step 505 creates a 
database entry for the transferring User using the infor- 
mation in the message. At step 506 it creates new keys 
for itself which are to be used in communicating with the 
User's Agent 110. At this point 'new' Courier background 
element 130 needs to know about this User, so step 507 
conveys the necessary information in a Distribute Account 
message that is substantially identical to the one in step 
316 of FIG. 3. 'New' Courier background element 130 
records this information in step 507a to activate this 
User's support there. 
[0049] n ow that 'new' Trusted Courier 103 is prepared to accept 
the transferring User, 'new' Courier foreground element 
120 informs 'old' Courier foreground element 120 of the 
parameters required for Agent 110 to access the new ac- 
count by sending a Configuration Update message to 'old' 
Courier foreground element 120 at step 508. These pa- 
rameters include network names and addresses for the 
servers that comprise 'new' Trusted Courier 103, as well 
as the messaging addresses and encryption/authenti- 
cation certificate to be used by Agent 110 when commu- 
nicating with 'new' Courier 103. Because this information 
goes first to 'old' Courier 103 and not directly to Agent 



110 from 'new' Courier 103, slamming by arbitrary would- 
be 'new' Couriers 103 is prevented. 

[0050] The next several steps in the Registration Transfer are ac- 
tually a special case of the Key Replacement procedure, in 
which the 'old' Courier 103 commands Agent 110 to ex- 
change keys with 'new' Courier 103. At steps 509-511, 
the Notice to Rekey message is sent from 'old' Courier 
foreground element 120, through 'old' Courier back- 
ground element 130 acting as a relay, to Agent 110, just 
as it is in steps 402-402b of FIG. 4. The difference here is 
that this message also carries the new configuration data 
pointing to 'new 1 Courier 103, which was conveyed previ- 
ously in the Configuration Update message at step 508. 
Agent 110 acts upon the Notice to Rekey at step 512 by 
creating new keys for itself, just as it does in step 403 of 
FIG. 4. In addition, at step 513 it acts upon the new con- 
figuration data in the message by changing its own con- 
figuration so that it refers to 'new' Courier 103. All subse- 
quent interactions with a Trusted Courier 103 will thus 
take place with 'new' Courier 103. 

[0051] The remainder of the Key Replacement is the same as in 
FIG. 4. Steps 514-521, in which Agent 110 and 'new' 
Courier 103 exchange their new keys and record them ac- 



cordingly, are substantially identical to steps 404-409. 
Similarly, the Background Key Replacement that occurs in 
steps 522 and 522a, whereby 'new' Courier foreground el- 
ement 120 informs 'new' Courier background element 130 
of the completed Key Replacement, is substantially identi- 
cal to the one in steps 411 and 412. 
[0052] Because the aforementioned Key Replacement occurs in 
the context of the ongoing Registration Transfer, 'old' 
Courier Pair 103 as the originator of the transaction is still 
unaware at this point that it has been completed. There- 
fore the new state of affairs are propagated back to 'old' 
Courier 103. The Transfer Complete message in step 523 
provides this closure. This message is sent from 'new 1 
Courier foreground element 120 to 'old' Courier fore- 
ground element 120 in parallel with the background ele- 
ment Key Replacement in step 522. Upon arrival, 'new' 
Courier foreground element 120 at step 524 changes the 
User's database entry so that it refers to 'new' Courier 103 
as the correct handler for this address, and propagates 
this change to 'old' Courier background element 130 in 
steps 525 and 526. Note that the Distribute Account mes- 
sage in step 525 is semantically identical to message of 
the same name in step 507, although the specific update 



to the account data is different in each case. At any rate, 
subsequent attempts to send a message to the transferred 
User or the corresponding Agent 110 via the 'old' Courier 
103 will therefore be rerouted to the 'new' Courier 103. At 
this point the User and corresponding Agent 110 are 
safely hosted on 'new' Trusted Courier 103 and no longer 
hosted on 'old' Trusted Courier 103. 

[0053] As long as the User's Registration status is active and sta- 
ble, that is, not in the process of executing one of the 
preceding procedures, the corresponding Agent 110 may 
create and send Private or Restricted messages to corre- 
spondents via the Trusted Courier 103 with which Agent 
110 is associated. FIG. 6 depicts exemplary processes 
which are followed to do so when both sender and recipi- 
ents are served by the same Courier 103. This diagram is 
derived from FIG. 7 of the foundation disclosure, con- 
densed for brevity where no change has been made and 
enhanced where necessary to describe what changes in 
the context of the present invention. 

[0054] First, at step 601 the sending User and Agent 110 will 

prepare the message, including composing it, marking it 
as Private or Restricted as appropriate, and commanding 
that it be sent. Also embodied in this step are the various 



conversion, encryption, and formatting actions that take 
place afterward, including construction and storage of the 
ARM Record. Though combined into a single step here, 
these items are substantially identical to steps 701-705 of 
FIG. 7 in the foundation disclosure. 
[0055] The Private or Restricted message thus prepared, it is set 
aside for the moment so the ARM Record can be sent first. 
Step 602 provides for the construction of an Access Re- 
strictions Message using the same recipient lists as the 
Private or Restricted message being processed, and con- 
taining the corresponding ARM Record. As detailed in the 
foundation disclosure, it is via this separate message that 
the ARM Record is conveyed to the recipients of the Pri- 
vate or Restricted message such that end-to-end message 
privacy is assured. In step 603, the Access Restrictions 
Message so composed is signed and encrypted according 
to the S/MIME email encryption standard (IETF document 
RFC1847) and sent to Trusted Courier Background 130. 
Step 604 shows the Access Restrictions Message being 
transported to Courier background element 130 and car- 
rying both the Message Identifier and the Content Encryp- 
tion Key, which are elements of the ARM Record. Upon ar- 
rival of the Access Restrictions Message at Courier back- 



ground element 130, at step 605 it is decrypted and vali- 
dated. These steps 602-605 taken together are substan- 
tially identical to steps 706-710 of the foundation disclo- 
sure. 

[0056] At this point the order of processing differs due to the 
separation of background and foreground handling into 
distinct elements. Where in the foundation disclosure it is 
the Access Restrictions Message that triggers Invitation of 
any unknown recipients, in the present invention that 
message is handled in Courier background element 130 
and is held pending Registration of unknown recipients by 
Courier foreground element 120. 

[0057] Thus for each recipient in the message header that is a 
Registered address, Courier background element 130 will 
in steps 606 and 607 find the appropriate set of keys, use 
them to create the S/MIME signature and transport en- 
cryption for the Access Request Message, and send the 
signed and encrypted Access Request Message to that re- 
cipient. Step 608 depicts this message in transit to the re- 
cipient, whose Agent 110 will in step 609 decrypt and val- 
idate the Access Restrictions Message, then store the en- 
closed ARM Record. These steps are substantially identical 
to steps 718-721 in FIG. 7 of the foundation disclosure. 



Again, this sequence is repeated for each known recipient. 
[0058] n ow in step 610, Courier background element 130 will 
make a copy of the Access Restrictions Message for each 
recipient that isn't already Registered in the system, creat- 
ing a new database entry for each one in preparation for 
their eventual Registration. Step 611 depicts Courier 
background element 130 quiescing at this point to await 
notice from Courier foreground element 120 that the Reg- 
istration has completed; this occurs, as usual, for each of 
the relevant addresses. Processing will resume at step 
628, but first the foreground handling is described. Note 
that good server hygiene practice will dictate that an im- 
plementation audit these outstanding messages and clean 
up any that have not been released within a reasonable 
time. 

[0059] Returning to the sender's Agent 110, the foreground mes- 
sage with the actual encrypted content, which was pre- 
pared previously in step 601, is wrapped in an S/MIME 
package (signed and encrypted) in step 612 and sent to 
the Courier foreground element 120 in step 613. Courier 
foreground element 120 unwraps the S/MIME package 
(decrypt and validate) in step 614. This sequence is sub- 
stantially identical to steps 722-726 in FIG. 7 of the foun- 



dation disclosure. Note that the Courier Receipt and cor- 
responding process steps described in the foundation dis- 
closure are implied here, though not shown in FIG. 6 for 
the sake of brevity. 
[0060] Now Trusted Courier foreground element 120 steps 

through the list of recipients' addresses in the header, de- 
termining which refer to registered users and which are 
unregistered as did Trusted Courier background element 
130 above. For each Registered recipient address, Courier 
foreground element 120 will retrieve the correct keys in 
step 615, rewrap the foreground message in an S/MIME 
package (signed and encrypted) in step 616, and send it 
to the corresponding Agent 110 in step 617. This se- 
quence is substantially identical to steps 727, 729, and 
730 in FIG. 7 of the foundation disclosure. As these mes- 
sages arrive at their respective destinations, each recipi- 
ent's Agent 110 will decrypt and validate the S/MIME 
package in step 618, find in step 619 the ARM Record 
stored previously at step 609, and use the content en- 
cryption key kept there to decrypt and present the mes- 
sage in step 620. This sequence is an abbreviated depic- 
tion of the detailed process described in the foundation 
disclosure. Specifically, steps 615-620 here are meant to 



be substantially identical to steps 727-738 there. 
[0061] The following sequence is repeated for each unknown re- 
cipient. Upon recognizing that the recipient address is not 
Registered, at step 621 the foreground message at hand 
will be copied into a new database entry created in antici- 
pation of the addressee's eventual Registration. Courier 
foreground element 120 will then, in step 622, initiate the 
process of Inviting the recipient to Register. This process 
is described in full in the foundation disclosure; it is used 
here exactly as it is there, and is represented here as a 
message flowing to the addressee in step 623. Following 
Invitation, the User's natural response is Registration, de- 
picted here as an interaction between Agent 110 and 
Courier foreground element 120 in step 624. This process 
has already been described in the context of FIG. 3. Note 
that the final steps of Registration include notifications at 
both Courier foreground element 120 and Courier back- 
ground element 130. These final steps are used as trig- 
gers by which each element detects that Registration is 
complete. Thus at step 625, Courier foreground element 
120 makes this detection, and so at step 626 it releases 
the held copy of the foreground message previously 
stored for the particular recipient whose Registration has 



just concluded. At step 627, then, Courier foreground ele- 
ment 120 returns to step 615 and processes the message 
for transmission to the recipient. Similarly, at step 628 
Courier background element 130 detects the completed 
Registration, at step 629 releases the held Access Restric- 
tions Message for that recipient, and at step 630 returns 
to step 606 to process the background message for 
transmission to the recipient's Agent 110. Once again, 
these steps are repeated for every Invited recipient that 
completes Registration. For those that don't after a rea- 
sonable time, implementations should practice good hy- 
giene and purge them. 

[0062] The remaining diagrams depict various message flow sce- 
narios involving multiple Couriers 103. So that these next 
sections do not entail the complication of describing the 
looping over multiple recipients, each scenario is shown 
with only a single recipient. However, it should be appar- 
ent that the system supports multiple recipients per mes- 
sage, and in fact the multi-recipient looping is implied in 
each of the cases that follow. 

[0063] FIG. 7 depicts the scenario in which the sender and the 
recipient are Registered in different Couriers 103, and 
those Couriers 103 both have been Introduced to one an- 



other. Note that Introduction scenarios are depicted in 
Figures 8 and 9, and will be described later. For now, the 
inter-Courier routing of messages will be clearer if we 
start with them already Introduced. 
[0064] The message flow begins as usual in step 701 with the 
preparation of a Private or Restricted message. Steps 
701-705, in which the message is created and prepared, 
and the Access Restrictions Message is sent to Courier 
background element 130, are substantially identical to 
steps 601-605 in FIG. 6. In step 706, however, the pro- 
cess differs because Courier background element 130 de- 
tects that the recipient address is served in another 
Courier 103. This detection can take one of two forms. If 
the sender's Courier 103 is Private (refer back to FIG. 2), 
that the recipient's domain is different from the sender's 
domain will denote that a different Courier 103 serves the 
recipient. If the sender's Courier 103 is Public, it can know 
a different Courier 103 serves this specific recipient ad- 
dress if a previous Introduction has taken place as de- 
scribed in FIG. 9 for this recipient. Any Courier 103, Public 
or Private, may also make this detection if the recipient's 
domain matches that of a Private Courier 103 that is sub- 
ordinate to the current one according to the certification 



hierarchy described in FIG. 2. 

[0065] Once the sender's Courier background element 130 has 
determined the recipient's Courier background element 
130, it will at step 707 imbed the Access Restrictions 
Message in an Inter-Courier message addressed to the re- 
cipient's Courier background element 130, and rewrap it 
in an S/MIME package (signed and encrypted) suitable for 
the destination Courier. The encryption key is found in the 
certificate provided by the recipient's Courier background 
element 130 during the aforementioned Introduction, 
while the signature key is that of the sender's Courier 
background element 130. Note that, unlike the certificates 
for Agent 110 communication, which are allocated per 
Registered address for both Courier and Agent, each 
Courier 103 Introduces itself to all other Couriers 103 us- 
ing the same certificate. 

[0066] | n s tep 708 the Access Restrictions Message, imbedded in 
the Inter-Courier message, is transported from the 
sender's Courier background element 130 to the recipi- 
ent's Courier background element 103. Upon arrival, at 
step 709 this message is unwrapped, decrypted, and vali- 
dated as usual. Steps 710-713, wherein the background 
message is rewrapped and transported to the recipient 



Agent 110, and there saved for future use, are substan- 
tially identical to steps 606-609 in FIG. 6 
[0067] Similarly, the foreground processing continues substan- 
tially identically to the single-Courier case, with steps 
714-716 moving the Private or Restricted message into 
the sender's Courier foreground element 120. At step 
717, the same routing decision that is made at step 706 
in the sender's Courier background element 130 is made 
in the sender's Courier foreground element 130. This 
brings to the fore the point that Introductions are propa- 
gated in parallel to both elements of a Trusted Courier 
103 so that they can both make the same routing deci- 
sions using the same criteria. This is an important at- 
tribute of the present invention, because it allows each 
Courier foreground element 120 and corresponding 
Courier background element 130 to operate in parallel 
with a minimum of synchronization points. All of these 
synchronization points have already been described in 
Figures 3, 4, and 5 with respect to Registration and the 
procedures that affect a User's account. No synchroniza- 
tion between Courier foreground element 120 and Courier 
background element 130 is required during message flow 
or Introduction, thus eliminating any opportunity to com- 



promise Private and Restricted messages. 

[0068] Because of the aforementioned parallelism, transport of 
the foreground message from the sender's Courier fore- 
ground element 120 to the recipient's Courier foreground 
element 120 is substantially identical to transport of the 
background message between the two Courier back- 
ground elements 130. Steps 717-720 are thus the same 
in the two Courier foreground elements 120 as steps 
706-709 in the two Courier background elements 130. As 
well, once the foreground message has arrived at the re- 
cipient's Courier foreground element 120, processing 
steps 721-726 to move it into Agent 110 and there 
present it to the User are substantially identical to steps 
615-620 in FIG. 6. 

[0069] The simplicity of this description demonstrates the ease 
with which the present invention handles the steady state 
message flow in the traffic mesh network of FIG. 2. How- 
ever, to establish this network requires Introduction pro- 
cedures. FIG. 8 depicts the scenario in which the sender's 
Trusted Courier 103 is a Private Courier, not permitted to 
serve Users outside its domain, that has not been Intro- 
duced to the recipient's Trusted Courier 103. 

[0070] | n FIG. 8. it should be noted that the foreground and 



background processing occur independently of one an- 
other and have essentially the same shape. This lack of 
interdependence is an important feature of the present in- 
vention. The parallelism will be exploited in the following 
description as well, by providing a single description for 
both foreground and background paths and noting that 
both are alike. 

[0071] As usual then, steps 801-803 prepare the message and 
transport the background component (the Access Restric- 
tions Message) to the sender's Courier background ele- 
ment 130, while steps 815-816 transport the foreground 
component to the sender's Courier foreground element 
120. This sequence is substantially identical to steps 
701-705 and 714-716 in FIG. 7, although they are de- 
picted in an even further condensed form. 

[0072] At steps 804 in Courier background element 130 and 817 
in Courier foreground element 120, the critical decision is 
made that the recipient's address cannot be served in this 
Trusted Courier 103, and is not known to be served in any 
other Trusted Courier 103 that has been Introduced to 
this one. Since this is a Private Courier, the decision is 
quite simple: the domain of the recipient's address does 
not match the domain of the sender's Courier 103, nor 



does it match the domain of any other Courier 103 to 
which this one has been Introduced. Therefore, the mes- 
sage is Deferred to the superior Courier 103. Refer to the 
discussion of the certification hierarchy in the context of 
FIG. 2 for a definition of the superior for each Trusted 
Courier 103. 

[0073] Deferral takes the form of wrapping the message at hand 
in an Inter-Courier message, performing the S/MIME sig- 
nature and encryption using appropriate keys, and send- 
ing the package to the appropriate member of the supe- 
rior Courier 103. Steps 805-806 and 818-819 depict this 
action. Note that in both foreground and background, the 
Inter-Courier package carries not only the corresponding 
message, but in this case it also carries the certificate of 
the sender's Courier 103 in order to begin the Introduc- 
tion. As the package is propagated to the proper Courier 
103 for the recipient, this certificate will go along and 
serve to Introduce each member of the recipient's Courier 
103 to the corresponding member of the sender's Courier 
103. 

[0074] one or more Superior Couriers 103 act upon the message 
as it is Deferred. At steps 807 and 820, the decision is 
made that this message should be directed to the corre- 



sponding member of the recipient's Courier 103. In this 
scenario that decision is substantially identical to the one 
made in steps 706 and 717 of FIG. 7. However, it is also 
possible that the immediate superior also does not know 
the recipient Courier 103, and executes another Deferral 
to its superior. Deferral can continue until the first Public 
Courier 103 is reached, which may be the Root Courier as 
described in the context of FIG. 2. FIG. 9 details what hap- 
pens at that point. Once a superior Courier 103 is reached 
at which the actual recipient's Courier 103 has been Intro- 
duced previously, the message is processed and relayed 
accordingly. Thus, steps 808-811 and 821-826 are sub- 
stantially identical to steps 707-713 and 718-726 of FIG. 
7. 

[0075] The members of the recipient's Courier 103 have not yet 
completed their processing, however. Noting at steps 812 
and 827 that an Introduction was carried by the message, 
the certificate and address from that Introduction are cap- 
tured in a new database entry for future reference. Subse- 
quent messages addressed to recipients in the domain of 
the sender's Courier 103 in this scenario will be routed di- 
rectly to that Courier 103 now that it has Introduced itself. 
The Introduction is then completed back to the first 



Courier 103 in order to close the loop. To do so the recip- 
ient's Courier background element 130 and Courier fore- 
ground element 120 each create an Introduction message 
and send it to the sender's Courier background element 
130 and Courier foreground element 120 respectively in 
steps 813 and 828. These Introduction messages contain 
the certificate and address of the recipient's Courier 103. 
Upon arrival in the sender's Courier 103, these Introduc- 
tion messages are consumed, and a new database entry is 
made for the recipient's Courier 103, its address and cer- 
tificate. Note that no coordination is required between the 
foreground and background planes, because they are each 
handled independently of one another, providing the 
same information without synchronization points in the 
protocol. 

[0076] | n FIG. 8 Introduction is driven by Deferral of a message 
from a Private Courier 103 to its superior Courier 103. 
This works well within and among Private Couriers 103, 
but as soon as the message reaches a Public Courier 103, 
whether by Deferral or directly from an Agent 110 served 
there, and a recipient address is unknown at that Public 
Courier 103, Invitation will take place as previously de- 
scribed. However, because multiple Public Couriers 103 



may exist in the network, and because not all Private 
Couriers 103 are known to all Public Couriers 103, it is 
quite possible for the Invitation to arrive at an existing 
Agent 110 that is Registered in a Courier 103 other than 
the Invitation's source. This is potentially a very confusing 
situation for the User, so appropriate automatic handling 
of the unwanted Invitation is required at Agent 110. FIG. 9 
depicts this scenario, and the following paragraphs de- 
scribe the necessary processing. 
[0077] Beginning at step 901, and continuing through step 908, 
FIG. 9 depicts what appears to be an ordinary message 
flow involving a single Trusted Courier 103 and a recipient 
whose address is unknown there. The processing in this 
sequence is substantially identical to steps 601-605, 
610-614, and 621-623 in FIG. 6, depicted here in a highly 
condensed fashion. Note, however, a small difference be- 
tween the Introduction message in step 908 and that of 
the foundation disclosure: the sender's Courier fore- 
ground element 120 includes its Introduction certificate in 
the message, and signs the entire Invitation. This change 
is actually a benefit even without the multi-Courier net- 
work, because it allows invited recipients an opportunity 
to validate the authenticity of the message. Nevertheless, 



while it would have been useful before it is critical here in 
order to trigger Introductions between the members of 
the sender's and recipient's Couriers 103. 

[0078] The key action in triggering these Introductions takes 

place in step 909. The Agent 110 which receives the Invi- 
tation from the sender's Courier foreground element 103 
knows itself to be Registered already in a different Courier 
103. Therefore, it rejects the unwanted Invitation by for- 
warding it to both members of its Courier 103. No User 
action is required unless Agent 110 is implemented in a 
loosely-coupled fashion as described in the foundation 
disclosure; even in that case the only action required is to 
open the message, whereupon the Agent 110 software is 
called and the process continues. 

[0079] The background rejection occurs first, with Agent 110 

forwarding the Invitation and its Introduction certificate to 
its (the recipient's) Courier background element 130 in an 
Invitation Reject message at step 910. Though not explicit 
in the diagram, this message is wrapped in the usual S/ 
MIME package (signed and encrypted) for proper transport 
protection and authentication. Upon receiving, decrypting, 
and validating this message, the recipient's Courier back- 
ground element 130 at step 911 extracts the Introduction 



certificate and creates a database entry for the sender's 
Courier background element 130 to which it points. Next, 
in step 912 an Introduction message is sent from the re- 
cipient's Courier background element 130 to the sender's 
Courier background element 130, encrypted using the lat- 
ter's certificate and carrying with it the former's certifi- 
cate. In addition, this Introduction message carries the 
original forwarded Invitation for correlation purposes. 
Upon receiving, decrypting, and validating this message, 
the sender's Courier background element 130 will at step 
913 conclude the Introduction by creating a database en- 
try for the recipient's Courier background element 130 
and storing the received certificate there. 
[0080] After the Introduction is complete between the two 

Courier Backgrounds 130, the pending Access Restrictions 
Message is handled. Remember that the sender's Courier 
background element 130 is holding that message, and 
awaiting notice from the corresponding Courier fore- 
ground element 120 that the addressed recipient has 
Registered. In order for the sender's Courier background 
element 130 to know that the recently completed Intro- 
duction is relevant to the pending message, the forwarded 
Invitation carried by the Introduction message in step 912 



is consulted. The original recipient's address is available 
there, so the sender's Courier background element 130 
can correlate the Introduction to the held message. 
Therefore, at step 914, it stops waiting for a Registration 
that will not occur, and instead records in the database 
entry for the recipient address that subsequent messages 
should be relayed to the just-Introduced Courier back- 
ground element 130. The pending Access Restrictions 
Message is released, to be relayed in the usual S/MIME 
package to the recipient's Courier background element 
130 via the InterCourier Message in step 915. The pro- 
cessing and signaling in steps 916-918, which move the 
Access Restrictions Message the rest of the way to its des- 
tination, are substantially identical to steps 709-713 of 
FIG. 7. 

[0081] with the background rejection complete, the foreground 
rejection can now be described. The steps taken are sub- 
stantially identical to those of the previous paragraph, ex- 
cept that the messages flow through and the actions are 
taken by the respective Courier Foregrounds 120. The In- 
vitation Reject message in step 919 is substantially identi- 
cal to the one in step 910, and the remainder of the Intro- 
duction in steps 920-922 is the same as steps 911-913. 



Similarly, canceling the Registration and releasing the held 
message in step 923 is the same as canceling the Regis- 
tration and releasing the held message in step 914. Fi- 
nally, now that the recipient's address is correlated with 
the correct Courier foreground element 120, the inter- 
Courier message propagation and final delivery shown in 
steps 924-929 are substantially identical to the same 
processing and signaling in steps 717-726 in FIG. 7. 
[0082] N 0te how the background and foreground rejections 

propagate independently of one another, as well as how 
the Introductions and message releases they trigger also 
flow without interaction between the various background 
and foreground elements of the Trusted Couriers 103 that 
are involved. This is yet another example of the robust in- 
terlock-free protocol design intended in the present in- 
vention. While the Foreground Invitation Reject in step 
919 is shown being sent after arrival and processing of 
the Access Restrictions Message in step 918, this is a de- 
scriptive convenience rather than a protocol requirement. 
In fact, in the preferred embodiment the Foreground Invi- 
tation Reject in step 919 is sent immediately after the 
Background Invitation Reject in step 910, thereby allowing 
Agent 110 to quiesce while the rest of the system does its 



work. Then the messages that arrive as a result will be 
handled asynchronously, just as they normally are in other 
scenarios. 

[0083] The invention has been described above with reference to 
preferred embodiments. It is not intended that the inven- 
tion be limited to the specific embodiments shown and 
described, but that the invention be limited in scope only 
by the claims appended hereto. It will be evident to those 
skilled in the art that various substitutions, modifications, 
and extensions may be made to the embodiments as well 
as to various technologies which are utilized in the em- 
bodiments. In particular, those skilled in the art will rec- 
ognize that the scenarios posed above are elementary in 
nature, and a working system will support numerous and 
various combinations of those scenarios in order to pro- 
vide the described services. That the infinitude of possible 
topologies, combinations, and scenario orderings are not 
explicitly enumerated here should not imply that they 
have not been adequately disclosed by the descriptions of 
fundamental elements given here. It will also be appreci- 
ated by those skilled in the art that such substitutions, 
modifications, and extensions fall within the spirit and 
scope of the invention, and it is intended that the inven- 



tion as set forth in the claims appended hereto includes 
all such substitutions, modifications, and extensions. 



